\chapter{数字签名(Digital Signatures)}
数字签名是利用密码技术，达到在数字通信中与纸质签名类似的效果。\par
下面是NIST对于数字签名(digital signature)的概述\footnote{\url{https://csrc.nist.gov/Projects/Digital-Signatures}}。\par
As an electronic analogue of a written signature, a digital signature provides assurance that:\par
\begin{itemize}
	\item the claimed signatory signed the information, and
	\item the information was not modified after signature generation.
\end{itemize}

Federal Information Processing Standard (FIPS) 186-4, Digital Signature Standard (DSS), specifies three NIST-approved digital signature algorithms: DSA, RSA, and ECDSA. All three are used to generate and verify digital signatures, in conjunction with an approved hash function specified in FIPS 180-4, Secure Hash Standard or FIPS 202, SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions.

\section{基于对称密钥算法的数字签名}
首先看到很多帖子说“数字签名（又称公钥数字签名）是只有信息的发送者才能产生的别人无法伪造的一段数字串，这段数字串同时也是对信息的发送者发送信息真实性的一个有效证明。”\footnote{\url{https://baike.baidu.com/item/数字签名}}
这种说法有点偏颇，只是现在数字签名很多场合都在使用公钥密码算法来实现，我们这里加了这一小节，我们引用卿斯汉老师书\cite{qing-cry}中一段话，概念性地给大家介绍一下对称密码算法的签名方案。\par

"
R. C. Merkle建议，如果有一个可以信赖的第三方TTP(trusted third party),用下面的方法可以用传统的密码系统实现数字签名。A将自己的一对可逆的秘密变换$E_A$和$D_A$告诉TTP，当A传送签名的信息M给B时，A计算出$C=D_A(M)$,然后将C发送给B。为了验证C并得到M，B将C传送给TTP。TTP计算出$E_A(C)=M$,然后通过B的秘密变换将M传送给B。用传统的密码系统实现数字签名还有许多其他方法，这里就不再介绍了。
"\cite{qing-cry}

\newpage

\section{数字签名的基本概念示例}
此节内容来自阮一峰的网络日志\footnote{阮一峰的网络日志为\url{http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html}}，其翻译了国外一个数字签名的介绍\footnote{What is a Digital Signature?An introduction to Digital Signatures, by David Youd,url is \url{http://www.youdzone.com/signature.html}}，形象，故此直接引用。\par
\begin{enumerate}
	\item 鲍勃有两把钥匙，一把是公钥，另一把是私钥。
	\begin{figure}[htbp]
		\centering
		\includegraphics[width=0.5\textwidth]{DS-example-01.png}
	\end{figure}
	\item 鲍勃把公钥送给他的朋友们----帕蒂、道格、苏珊----每人一把。
	\begin{figure}[htbp]
		\centering
		\includegraphics[width=0.5\textwidth]{DS-example-02.png}
	\end{figure}
	\item 苏珊要给鲍勃写一封保密的信。她写完后用鲍勃的公钥加密，就可以达到保密的效果。
	\begin{figure}[htbp]
		\centering
		\includegraphics[width=0.5\textwidth]{DS-example-03.png}
	\end{figure}
	\item 鲍勃收信后，用私钥解密，就看到了信件内容。这里要强调的是，只要鲍勃的私钥不泄露，这封信就是安全的，即使落在别人手里，也无法解密。
	\begin{figure}[htbp]
		\centering
		\includegraphics[width=0.5\textwidth]{DS-example-04.png}
	\end{figure}
	\item 鲍勃给苏珊回信，决定采用"数字签名"。他写完后先用Hash函数，生成信件的摘要（digest）。
	\begin{figure}[htbp]
		\centering
		\includegraphics[width=0.5\textwidth]{DS-example-05.png}
	\end{figure}
	\item 然后，鲍勃使用私钥，对这个摘要加密，生成"数字签名"（signature）。
	\begin{figure}[htbp]
		\centering
		\includegraphics[width=0.5\textwidth]{DS-example-06.png}
	\end{figure}
	\item 鲍勃将这个签名，附在信件下面，一起发给苏珊。\par
		\centerline{
			\includegraphics[width=0.5\textwidth]{DS-example-07.png}
		}
	
	\item 苏珊收信后，取下数字签名，用鲍勃的公钥解密，得到信件的摘要。由此证明，这封信确实是鲍勃发出的。\par
			\centerline{
				\includegraphics[width=0.5\textwidth]{DS-example-08.png}
			}
	
	\item 苏珊再对信件本身使用Hash函数，将得到的结果，与上一步得到的摘要进行对比。如果两者一致，就证明这封信未被修改过。\par
			\centerline{
				\includegraphics[width=0.5\textwidth]{DS-example-09.png}
			}
		
	\item 复杂的情况出现了。道格想欺骗苏珊，他偷偷使用了苏珊的电脑，用自己的公钥换走了鲍勃的公钥。此时，苏珊实际拥有的是道格的公钥，但是还以为这是鲍勃的公钥。因此，道格就可以冒充鲍勃，用自己的私钥做成"数字签名"，写信给苏珊，让苏珊用假的鲍勃公钥进行解密。\par
	\centerline{
		\includegraphics[width=0.5\textwidth]{DS-example-10.png}
	}
	
	\item 后来，苏珊感觉不对劲，发现自己无法确定公钥是否真的属于鲍勃。她想到了一个办法，要求鲍勃去找"证书中心"（certificate authority，简称CA），为公钥做认证。证书中心用自己的私钥，对鲍勃的公钥和一些相关信息一起加密，生成"数字证书"（Digital Certificate）。\par
	\centerline{
		\includegraphics[width=0.5\textwidth]{DS-example-11.png}
	}

	\item 鲍勃拿到数字证书以后，就可以放心了。以后再给苏珊写信，只要在签名的同时，再附上数字证书就行了。\par
	\centerline{
		\includegraphics[width=0.5\textwidth]{DS-example-12.png}
	}
	
	\item 苏珊收信后，用CA的公钥解开数字证书，就可以拿到鲍勃真实的公钥了，然后就能证明"数字签名"是否真的是鲍勃签的。\par
	\centerline{
		\includegraphics[width=0.5\textwidth]{DS-example-13.png}
	}
	
\end{enumerate}


\section{证书实例}
下图就是我们用OpenSSL生成了BUU的CA公私钥证书，然后再用OpenSSL生成个人的公私钥对，用BUU CA颁发的证书(.cer)文件中的内容，图\ref{cert-example}是用Thunderbird内的证书查看工具看到的内容。\par

\begin{figure}[htbp]
	\centering
	\includegraphics[width=0.5\textwidth]{cert-example.PNG}
	\caption{一个证书文件中的内容}
	\label{cert-example}
\end{figure}
\par

目前常用的证书相关标准是ITU-T的PKI(Public key Infrastructure)系列标准X.509，下面我给出一个英文帖子“PEM, DER, CRT, and CER: X.509 Encodings and Conversions”\footnote{帖子的URL地址为\url{https://www.ssl.com/guide/pem-der-crt-and-cer-x-509-encodings-and-conversions/}}作为大家的阅读资料，同时了解一下证书的格式。\par


\subsection{PEM, DER, CRT, and CER: X.509 Encodings and Conversions}
You may have seen digital certificate files with a variety of filename extensions, such as .crt, .cer, .pem, or .der. These extensions generally map to two major encoding schemes for X.509 certificates and keys: PEM (Base64 ASCII), and DER (binary). However, there is some overlap and other extensions are used, so you can’t always tell what kind of file you are working with just from looking at the filename; you may need to open it in a text editor and take a look for yourself.
\par
As you work with digital certificates, you may find yourself with the need to convert between PEM and DER files, view their contents as human-readable text, or combine them into common container formats like PKCS\#12 or PKCS\#7. This guide points out the major differences between PEM and DER files and common filename extensions associated with them. It also provides visual examples of each encoding, and illustrates some common file format conversions with OpenSSL.

\subsubsection{What is OpenSSL?}
OpenSSL is a very useful open-source command-line toolkit for working with X.509 certificates, certificate signing requests (CSRs), and cryptographic keys. If you are using a UNIX variant like Linux or macOS, OpenSSL is probably already installed on your computer. If you would like to use OpenSSL on Windows, you can enable Windows 10’s Linux subsystem or install Cygwin.

\subsubsection{PEM}
PEM (originally “Privacy Enhanced Mail”) is the most common format for X.509 certificates, CSRs, and cryptographic keys. A PEM file is a text file containing one or more items in Base64 ASCII encoding, each with plain-text headers and footers (e.g. -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----). A single PEM file could contain an end-entity certificate, a private key, or multiple certificates forming a complete chain of trust. Most certificate files downloaded from SSL.com will be in PEM format.
\par

\textbf{PEM Filename Extensions}
\par
PEM files are usually seen with the extensions .crt, .pem, .cer, and .key (for private keys), but you may also see them with different extensions. For example, the SSL.com CA bundle file available from the download table in a certificate order has the extension .ca-bundle.
\par

\textbf{What does a PEM certificate look like?}
\par
The SSL/TLS certificate for www.ssl.com is shown below in PEM format :
\par

\begin{lstlisting}
-----BEGIN CERTIFICATE-----
MIIH/TCCBeWgAwIBAgIQaBYE3/M08XHYCnNVmcFBcjANBgkqhkiG9w0BAQsFADBy
MQswCQYDVQQGEwJVUzEOMAwGA1UECAwFVGV4YXMxEDAOBgNVBAcMB0hvdXN0b24x
ETAPBgNVBAoMCFNTTCBDb3JwMS4wLAYDVQQDDCVTU0wuY29tIEVWIFNTTCBJbnRl
cm1lZGlhdGUgQ0EgUlNBIFIzMB4XDTIwMDQwMTAwNTgzM1oXDTIxMDcxNjAwNTgz
M1owgb0xCzAJBgNVBAYTAlVTMQ4wDAYDVQQIDAVUZXhhczEQMA4GA1UEBwwHSG91
c3RvbjERMA8GA1UECgwIU1NMIENvcnAxFjAUBgNVBAUTDU5WMjAwODE2MTQyNDMx
FDASBgNVBAMMC3d3dy5zc2wuY29tMR0wGwYDVQQPDBRQcml2YXRlIE9yZ2FuaXph
dGlvbjEXMBUGCysGAQQBgjc8AgECDAZOZXZhZGExEzARBgsrBgEEAYI3PAIBAxMC
VVMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHheRkbb1FCc7xRKst
wK0JIGaKY8t7JbS2bQ2b6YIJDgnHuIYHqBrCUV79oelikkokRkFvcvpaKinFHDQH
UpWEI6RUERYmSCg3O8Wi42uOcV2B5ZabmXCkwdxY5Ecl51BbM8UnGdoAGbdNmiRm
SmTjcs+lhMxg4fFY6lBpiEVFiGUjGRR+61R67Lz6U4KJeLNcCm07QwFYKBmpi08g
dygSvRdUw55Jopredj+VGtjUkB4hFT4GQX/ght69Rlqz/+8u0dEQkhuUuucrqalm
SGy43HRwBfDKFwYeWM7CPMd5e/dO+t08t8PbjzVTTv5hQDCsEYIV2T7AFI9ScNxM
kh7/AgMBAAGjggNBMIIDPTAfBgNVHSMEGDAWgBS/wVqH/yj6QT39t0/kHa+gYVgp
vTB/BggrBgEFBQcBAQRzMHEwTQYIKwYBBQUHMAKGQWh0dHA6Ly93d3cuc3NsLmNv
bS9yZXBvc2l0b3J5L1NTTGNvbS1TdWJDQS1FVi1TU0wtUlNBLTQwOTYtUjMuY3J0
MCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcHMuc3NsLmNvbTAfBgNVHREEGDAWggt3
d3cuc3NsLmNvbYIHc3NsLmNvbTBfBgNVHSAEWDBWMAcGBWeBDAEBMA0GCyqEaAGG
9ncCBQEBMDwGDCsGAQQBgqkwAQMBBDAsMCoGCCsGAQUFBwIBFh5odHRwczovL3d3
dy5zc2wuY29tL3JlcG9zaXRvcnkwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF
BwMBMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmxzLnNzbC5jb20vU1NMY29t
LVN1YkNBLUVWLVNTTC1SU0EtNDA5Ni1SMy5jcmwwHQYDVR0OBBYEFADAFUIazw5r
ZIHapnRxIUnpw+GLMA4GA1UdDwEB/wQEAwIFoDCCAX0GCisGAQQB1nkCBAIEggFt
BIIBaQFnAHcA9lyUL9F3MCIUVBgIMJRWjuNNExkzv98MLyALzE7xZOMAAAFxM0ho
bwAABAMASDBGAiEA6xeliNR8Gk/63pYdnS/vOx/CjptEMEv89WWh1/urWIECIQDy
BreHU25DzwukQaRQjwW655ZLkqCnxbxQWRiOemj9JAB1AJQgvB6O1Y1siHMfgosi
LA3R2k1ebE+UPWHbTi9YTaLCAAABcTNIaNwAAAQDAEYwRAIgGRE4wzabNRdD8kq/
vFP3tQe2hm0x5nXulowh4Ibw3lkCIFYb/3lSDplS7AcR4r+XpWtEKSTFWJmNCRbc
XJur2RGBAHUA7sCV7o1yZA+S48O5G8cSo2lqCXtLahoUOOZHssvtxfkAAAFxM0ho
8wAABAMARjBEAiB6IvboWss3R4ItVwjebl7D3yoFaX0NDh2dWhhgwCxrHwIgCfq7
ocMC5t+1ji5M5xaLmPC4I+WX3I/ARkWSyiO7IQcwDQYJKoZIhvcNAQELBQADggIB
ACeuur4QnujqmguSrHU3mhf+cJodzTQNqo4tde+PD1/eFdYAELu8xF+0At7xJiPY
i5RKwilyP56v+3iY2T9lw7S8TJ041VLhaIKp14MzSUzRyeoOAsJ7QADMClHKUDlH
UU2pNuo88Y6igovT3bsnwJNiEQNqymSSYhktw0taduoqjqXn06gsVioWTVDXysd5
qEx4t6sIgIcMm26YH1vJpCQEhKpc2y07gRkklBZRtMjThv4cXyyMX7uTcdT7AJBP
ueifCoV25JxXuo8d5139gwP1BAe7IBVPx2u7KN/UyOXdZmwMf/TmFGwDdCfsyHf/
ZsB2wLHozTYoAVmQ9FoU1JLgcVivqJ+vNlBhHXhlxMdN0j80R9Nz6EIglQjeK3O8
I/cFGm/B8+42hOlCId9ZdtndJcRJVji0wD0qwevCafA9jJlHv/jsE+I9Uz6cpCyh
sw+lrFdxUgqU58axqeK89FR+No4q0IIO+Ji1rJKr9nkSB0BqXozVnE1YB/KLvdIs
uYZJuqb2pKku+zzT6gUwHUTZvBiNOtXL4Nxwc/KT7WzOSd2wP10QI8DKg4vfiNDs
HWmB1c4Kji6gOgA5uSUzaGmq/v4VncK5Ur+n9LbfnfLc28J5ft/GotinMyDk3iar
F10YlqcOmeX1uFmKbdi/XorGlkCoMF3TDx8rmp9DBiB/
-----END CERTIFICATE-----
\end{lstlisting}

\subsubsection{DER}
DER (Distinguished Encoding Rules) is a binary encoding for X.509 certificates and private keys. Unlike PEM, DER-encoded files do not contain plain text statements such as -----BEGIN CERTIFICATE-----. DER files are most commonly seen in Java contexts.
\par
\textbf{DER Filename Extensions}\par
DER-encoded files are usually found with the extensions .der and .cer.
\par
\textbf{What does a DER-encoded certificate look like?}\par
The DER-encoded SSL/TLS certificate for www.ssl.com is shown below (click to view):
\par

\begin{lstlisting}
3082 07fd 3082 05e5 a003 0201 0202 1068
1604 dff3 34f1 71d8 0a73 5599 c141 7230
0d06 092a 8648 86f7 0d01 010b 0500 3072
310b 3009 0603 5504 0613 0255 5331 0e30
0c06 0355 0408 0c05 5465 7861 7331 1030
0e06 0355 0407 0c07 486f 7573 746f 6e31
1130 0f06 0355 040a 0c08 5353 4c20 436f
7270 312e 302c 0603 5504 030c 2553 534c
2e63 6f6d 2045 5620 5353 4c20 496e 7465
726d 6564 6961 7465 2043 4120 5253 4120
5233 301e 170d 3230 3034 3031 3030 3538
3333 5a17 0d32 3130 3731 3630 3035 3833
335a 3081 bd31 0b30 0906 0355 0406 1302
5553 310e 300c 0603 5504 080c 0554 6578
6173 3110 300e 0603 5504 070c 0748 6f75
7374 6f6e 3111 300f 0603 5504 0a0c 0853
534c 2043 6f72 7031 1630 1406 0355 0405
130d 4e56 3230 3038 3136 3134 3234 3331
1430 1206 0355 0403 0c0b 7777 772e 7373
6c2e 636f 6d31 1d30 1b06 0355 040f 0c14
5072 6976 6174 6520 4f72 6761 6e69 7a61
7469 6f6e 3117 3015 060b 2b06 0104 0182
373c 0201 020c 064e 6576 6164 6131 1330
1106 0b2b 0601 0401 8237 3c02 0103 1302
5553 3082 0122 300d 0609 2a86 4886 f70d
0101 0105 0003 8201 0f00 3082 010a 0282
0101 00c7 85e4 646d bd45 09ce f144 ab2d
c0ad 0920 668a 63cb 7b25 b4b6 6d0d 9be9
8209 0e09 c7b8 8607 a81a c251 5efd a1e9
6292 4a24 4641 6f72 fa5a 2a29 c51c 3407
5295 8423 a454 1116 2648 2837 3bc5 a2e3
6b8e 715d 81e5 969b 9970 a4c1 dc58 e447
25e7 505b 33c5 2719 da00 19b7 4d9a 2466
4a64 e372 cfa5 84cc 60e1 f158 ea50 6988
4545 8865 2319 147e eb54 7aec bcfa 5382
8978 b35c 0a6d 3b43 0158 2819 a98b 4f20
7728 12bd 1754 c39e 49a2 9ade 763f 951a
d8d4 901e 2115 3e06 417f e086 debd 465a
b3ff ef2e d1d1 1092 1b94 bae7 2ba9 a966
486c b8dc 7470 05f0 ca17 061e 58ce c23c
c779 7bf7 4efa dd3c b7c3 db8f 3553 4efe
6140 30ac 1182 15d9 3ec0 148f 5270 dc4c
921e ff02 0301 0001 a382 0341 3082 033d
301f 0603 551d 2304 1830 1680 14bf c15a
87ff 28fa 413d fdb7 4fe4 1daf a061 5829
bd30 7f06 082b 0601 0505 0701 0104 7330
7130 4d06 082b 0601 0505 0730 0286 4168
7474 703a 2f2f 7777 772e 7373 6c2e 636f
6d2f 7265 706f 7369 746f 7279 2f53 534c
636f 6d2d 5375 6243 412d 4556 2d53 534c
2d52 5341 2d34 3039 362d 5233 2e63 7274
3020 0608 2b06 0105 0507 3001 8614 6874
7470 3a2f 2f6f 6373 7073 2e73 736c 2e63
6f6d 301f 0603 551d 1104 1830 1682 0b77
7777 2e73 736c 2e63 6f6d 8207 7373 6c2e
636f 6d30 5f06 0355 1d20 0458 3056 3007
0605 6781 0c01 0130 0d06 0b2a 8468 0186
f677 0205 0101 303c 060c 2b06 0104 0182
a930 0103 0104 302c 302a 0608 2b06 0105
0507 0201 161e 6874 7470 733a 2f2f 7777
772e 7373 6c2e 636f 6d2f 7265 706f 7369
746f 7279 301d 0603 551d 2504 1630 1406
082b 0601 0505 0703 0206 082b 0601 0505
0703 0130 4806 0355 1d1f 0441 303f 303d
a03b a039 8637 6874 7470 3a2f 2f63 726c
732e 7373 6c2e 636f 6d2f 5353 4c63 6f6d
2d53 7562 4341 2d45 562d 5353 4c2d 5253
412d 3430 3936 2d52 332e 6372 6c30 1d06
0355 1d0e 0416 0414 00c0 1542 1acf 0e6b
6481 daa6 7471 2149 e9c3 e18b 300e 0603
551d 0f01 01ff 0404 0302 05a0 3082 017d
060a 2b06 0104 01d6 7902 0402 0482 016d
0482 0169 0167 0077 00f6 5c94 2fd1 7730
2214 5418 0830 9456 8ee3 4d13 1933 bfdf
0c2f 200b cc4e f164 e300 0001 7133 4868
6f00 0004 0300 4830 4602 2100 eb17 a588
d47c 1a4f fade 961d 9d2f ef3b 1fc2 8e9b
4430 4bfc f565 a1d7 fbab 5881 0221 00f2
06b7 8753 6e43 cf0b a441 a450 8f05 bae7
964b 92a0 a7c5 bc50 5918 8e7a 68fd 2400
7500 9420 bc1e 8ed5 8d6c 8873 1f82 8b22
2c0d d1da 4d5e 6c4f 943d 61db 4e2f 584d
a2c2 0000 0171 3348 68dc 0000 0403 0046
3044 0220 1911 38c3 369b 3517 43f2 4abf
bc53 f7b5 07b6 866d 31e6 75ee 968c 21e0
86f0 de59 0220 561b ff79 520e 9952 ec07
11e2 bf97 a56b 4429 24c5 5899 8d09 16dc
5c9b abd9 1181 0075 00ee c095 ee8d 7264
0f92 e3c3 b91b c712 a369 6a09 7b4b 6a1a
1438 e647 b2cb edc5 f900 0001 7133 4868
f300 0004 0300 4630 4402 207a 22f6 e85a
cb37 4782 2d57 08de 6e5e c3df 2a05 697d
0d0e 1d9d 5a18 60c0 2c6b 1f02 2009 fabb
a1c3 02e6 dfb5 8e2e 4ce7 168b 98f0 b823
e597 dc8f c046 4592 ca23 bb21 0730 0d06
092a 8648 86f7 0d01 010b 0500 0382 0201
0027 aeba be10 9ee8 ea9a 0b92 ac75 379a
17fe 709a 1dcd 340d aa8e 2d75 ef8f 0f5f
de15 d600 10bb bcc4 5fb4 02de f126 23d8
8b94 4ac2 2972 3f9e affb 7898 d93f 65c3
b4bc 4c9d 38d5 52e1 6882 a9d7 8333 494c
d1c9 ea0e 02c2 7b40 00cc 0a51 ca50 3947
514d a936 ea3c f18e a282 8bd3 ddbb 27c0
9362 1103 6aca 6492 6219 2dc3 4b5a 76ea
2a8e a5e7 d3a8 2c56 2a16 4d50 d7ca c779
a84c 78b7 ab08 8087 0c9b 6e98 1f5b c9a4
2404 84aa 5cdb 2d3b 8119 2494 1651 b4c8
d386 fe1c 5f2c 8c5f bb93 71d4 fb00 904f
b9e8 9f0a 8576 e49c 57ba 8f1d e75d fd83
03f5 0407 bb20 154f c76b bb28 dfd4 c8e5
dd66 6c0c 7ff4 e614 6c03 7427 ecc8 77ff
66c0 76c0 b1e8 cd36 2801 5990 f45a 14d4
92e0 7158 afa8 9faf 3650 611d 7865 c4c7
4dd2 3f34 47d3 73e8 4220 9508 de2b 73bc
23f7 051a 6fc1 f3ee 3684 e942 21df 5976
d9dd 25c4 4956 38b4 c03d 2ac1 ebc2 69f0
3d8c 9947 bff8 ec13 e23d 533e 9ca4 2ca1
b30f a5ac 5771 520a 94e7 c6b1 a9e2 bcf4
547e 368e 2ad0 820e f898 b5ac 92ab f679
1207 406a 5e8c d59c 4d58 07f2 8bbd d22c
b986 49ba a6f6 a4a9 2efb 3cd3 ea05 301d
44d9 bc18 8d3a d5cb e0dc 7073 f293 ed6c
ce49 ddb0 3f5d 1023 c0ca 838b df88 d0ec
1d69 81d5 ce0a 8e2e a03a 0039 b925 3368
69aa fefe 159d c2b9 52bf a7f4 b6df 9df2
dcdb c279 7edf c6a2 d8a7 3320 e4de 26ab
175d 1896 a70e 99e5 f5b8 598a 6dd8 bf5e
8ac6 9640 a830 5dd3 0f1f 2b9a 9f43 0620
7f
\end{lstlisting}

\subsubsection{Convert PEM certificate with chain of trust to PKCS\#7}
PKCS\#7 (also known as P7B) is a container format for digital certificates that is most often found in Windows and Java server contexts, and usually has the extension .p7b. PKCS\#7 files are not used to store private keys. In the example below, -certfile MORE.pem represents a file with chained intermediate and root certificates (such as a .ca-bundle file downloaded from SSL.com).
\par
\textit{Example:} openssl crl2pkcs7 -nocrl -certfile CERTIFICATE.pem -certfile MORE.pem -out CERTIFICATE.p7b
\par

\subsubsection{Convert PEM certificate with chain of trust and private key to PKCS\#12}
PKCS\#12 (also known as PKCS12 or PFX) is a common binary format for storing a certificate chain and private key in a single, encryptable file, and usually have the filename extensions .p12 or .pfx. In the example below, -certfile MORE.pem adds a file with chained intermediate and root certificates (such as a .ca-bundle file downloaded from SSL.com), and -inkey PRIVATEKEY.key adds the private key for CERTIFICATE.crt(the end-entity certificate). Please see this how-to for a more detailed explanation of the command shown.
\par
\textit{Example:} openssl pkcs12 -export -out CERTIFICATE.pfx -inkey PRIVATEKEY.key -in CERTIFICATE.crt -certfile MORE.crt
\par
After executing the command above you will be prompted to create a password to protect the PKCS\#12 file. Remember this password. You will need it to access any certificates and keys stored in the file.

\subsubsection{Convert DER-encoded certificate with chain of trust and private key to PKCS\#12}
To convert a DER certificate to PKCS\#12 it should first be converted to PEM, then combined with any additional certificates and/or private key as shown above. For a more detailed description of converting DER to PKCS\#12, please see \underline{this how-to}\footnote{Create a .pfx/.p12 Certificate File Using OpenSSL，网络地址\url{https://www.ssl.com/how-to/create-a-pfx-p12-certificate-file-using-openssl/}}.


\subsection{证书服务公司}
基于PKI体系，在我国目前有很多提供数字证书服务的公司，这些公司在支撑电子政务的同时，也向社会提供服务，比如北京数字认证股份有限公司(网址\url{https://www.bjca.cn/})、南京数字认证有限公司(网址\url{http://www.njca.com.cn/})、上海市数字证书认证中心有限公司(公司网址\url{https://www.sheca.com/})等，还有提供证书服务的公司有阿里云、天威诚信、TurstAsia等。


\newpage

\section{Https实例}
我们经常会用到https协议，这个协议主要用于网页加密，这就是一个应用"数字证书"的实例。以下这个例子来自于阮一峰的网络日志\footnote{阮一峰的网络日志为\url{http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html}}。

	\begin{figure}[htbp]
		\centering
		\includegraphics[width=0.5\textwidth]{dc-example-1.png}
	\end{figure}
\begin{enumerate}
	\item 首先，客户端向服务器发出加密请求。\par
		\centerline{
			\includegraphics[width=0.5\textwidth]{dc-example-2.png}
		}
			
	\item 服务器用自己的私钥加密网页以后，连同本身的数字证书，一起发送给客户端。\par
		\centerline{
			\includegraphics[width=0.5\textwidth]{dc-example-3.png}
		}


	\item 客户端（浏览器）的"证书管理器"，有"受信任的根证书颁发机构"列表。客户端会根据这张列表，查看解开数字证书的公钥是否在列表之内。\par
		\centerline{
			\includegraphics[width=0.5\textwidth]{dc-example-4.png}
		}
	
	\item 如果数字证书记载的网址，与你正在浏览的网址不一致，就说明这张证书可能被冒用，浏览器会发出警告。\par
		\centerline{
			\includegraphics[width=0.5\textwidth]{dc-example-5.png}
		}
	
	\item 如果这张数字证书不是由受信任的机构颁发的，浏览器会发出另一种警告。\par
		\centerline{
			\includegraphics[width=0.5\textwidth]{dc-example-6.png}
		}
	
	\item 如果数字证书是可靠的，客户端就可以使用证书中的服务器公钥，对信息进行加密，然后与服务器交换加密信息。\par
		\centerline{
			\includegraphics[width=0.5\textwidth]{dc-example-7.png}
		}
\end{enumerate}


\section{Https标准}
Https的意思是“HTTP Over TLS”,此协议是IETF Request for Comments: 2818  HTTP Over TLS。TLS是SSL协议的升级版，SSL/TLS是介于Https和TCP之间的协议。
Https是IETF的RFC 2818 “HTTP Over TLS”标准，利用TLS层提供的服务进行安全通信，如果看RFC2818标准，你会看到描述很简单，详细的初始化、密钥交换协议都是在TLS层实现，TLS也是IETF的标准，标准号为RFC 8446 ,标准名为"The Transport Layer Security (TLS) Protocol Version 1.3"，我们可以看到在这个标准中，认证用的是公钥体制，加密用的对称加密体制，在协议中定义了AES加密选项，密钥交换使用的是Diffie-Hellman协议。


\newpage

\section{签名方案与标准}

\subsection{DSS}
DSS(Digital Signature Standard)是美国的国家标准，目前最新发布的是2013版\footnote{最新版可以从美国NIST网站上下载，地址为\url{https://www.nist.gov/publications/digital-signature-standard-dss-2}}，其封皮如图\ref{dss-2013-cover}。
\begin{figure}[htbp]
	\centering
	\includegraphics[width=0.5\textwidth]{DSS-SPECIFIC-2013.PNG}
	\caption{2013年发布的DSS}
	\label{dss-2013-cover}
\end{figure}
在DSS 2013版中，对DSS概要描述见图\ref{dss-2013-intruduction}。
\begin{figure}[htbp]
	\centering
	\includegraphics[width=0.8\textwidth]{DS-introduction.PNG}
	\caption{2013年发布的DSS中的Introduction部分}
	\label{dss-2013-intruduction}
\end{figure}
而DSS的基本过程如图\ref{ds-process}。
\begin{figure}[htbp]
	\centering
	\includegraphics[width=0.5\textwidth]{DS-PROCESS.PNG}
	\caption{2013年发布的DSS中的Introduction部分}
	\label{ds-process}
\end{figure}

\par
从文档描述中我们可看到，DSS标准支持三种签名算法：DSA(Digital Signature Algorithm)、RSA Digital Signature Algorithm、Elliptic Curve Digital Signature Algorithm (ECDSA)。\par

FIPS 186-2 Specification for the DIGITAL SIGNATURE STANDARD(DSS)对于数据签名算法(简写为ds)的一般性描述如下：\\
A ds algorithm is used by a signatory to generate a digital signature on data and by a verifier to
verify the authenticity of the signature. Each signatory has a public and private key. The private key
is used in the signature generation process and the public key is used in the signature verification
process. For both signature generation and verification, the data which is referred to as a message,
M, is reduced by means of the Secure Hash Algorithm (SHA-1) specified in FIPS 180-1. An
adversary, who does not know the private key of the signatory, cannot generate the correct signature
of the signatory. In other words, signatures cannot be forged. However, by using the signatory's
public key, anyone can verify a correctly signed message. A means of associating public and private
key pairs to the corresponding users is required. That is, there must be a binding of a user's identity
and the user's public key. This binding may be certified by a mutually trusted party. For example,
a certifying authority could sign credentials containing a user's public key and identity to form a
certificate. Systems for certifying credentials and distributing certificates are beyond the scope of
this standard. NIST intends to publish separate document(s) on certifying credentials and distributing
certificates.

\subsubsection{DSA\footnote{摘抄自FIPS 186-2 Specifications for the DIGITAL SIGNATURE STANDARD (DSS) }}
\textbf{1.DSA参数(DSA parameters)}\par
The DSA makes use of the following parameters:
\begin{enumerate}
	\item p = a prime modulus, where $2^{L-1} < p < 2^{L}$ for $512 \leq L \leq 1024$ and L a multiple of 64
	\item q = a prime divisor of p - 1, where $2^{159} < q < 2^{160}$
	\item g = $h^{(p-1)/q} \pmod{p}$, where h is any integer with $1 < h < p - 1$ such that $h^{ (p-1)/q} \pmod{p} > 1$
	(g has order q mod p)
	\item x = a randomly or pseudorandomly generated integer with $0 < x < q$
	\item $y = g^{x} \pmod{p}$
	\item k = a randomly or pseudorandomly generated integer with $0 < k < q$
\end{enumerate}

The integers p, q, and g can be public and can be common to a group of users. A user's private and
public keys are x and y, respectively. They are normally fixed for a period of time. Parameters x
and k are used for signature generation only, and must be kept secret. Parameter k must be
regenerated for each signature.\par
Parameters p and q shall be generated as specified in Appendix 2, or using other FIPS approved
security methods. Parameters x and k shall be generated as specified in Appendix 3, or using other
FIPS approved security methods.\par

\vspace{1cm}
\textbf{2.DSA签名生成(DSA signature generation)}\par

The signature of a message M is the pair of numbers r and s computed according to the equations
below:\\
$r = (g^k \pmod{p}) \pmod{q}$ and\\
$s = (k^{-1} (SHA-1(M) + xr)) \pmod{q}.$\par
In the above, k -1 is the multiplicative inverse of k, mod q; i.e., (k -1 k) mod q = 1 and 0 < k -1 < q. The
value of SHA-1(M) is a 160-bit string output by the Secure Hash Algorithm specified in FIPS 180-1.
For use in computing s, this string must be converted to an integer. The conversion rule is given
in Appendix 2.2.\par

As an option, one may wish to check if r = 0 or s = 0. If either r = 0 or s = 0, a new value of k should
be generated and the signature should be recalculated (it is extremely unlikely that r = 0 or s = 0 if
signatures are generated properly).\par

The signature is transmitted along with the message to the verifier.

\vspace{1cm}
\textbf{3.DSA签名验证(DSA signature verification)}\par
Prior to verifying the signature in a signed message, p, q and g plus the sender's public key and
identity are made available to the verifier in an authenticated manner.\par

Let $M'$, $r'$, and $s'$ be the received versions of M, r, and s, respectively, and let y be the public key of
the signatory. To verify the signature, the verifier first checks to see that $0 < r' < q$ and $0 < s' < q$;
if either condition is violated the signature shall be rejected. If these two conditions are satisfied,
the verifier computes:
\\
$
w = (s')^{-1} \pmod{q} \\
u1 = ((SHA-1(M'))w) \pmod{q}\\
u2 = ((r')w) \pmod{q}\\
v = (((g)^{u1} (y)^{u2} ) \pmod{p}) \pmod{q}\\
$

\par
If $v = r'$, then the signature is verified and the verifier can have high confidence that the received
message was sent by the party holding the secret key x corresponding to y. For a proof that $v = r'$
when $M' = M$, $r' = r$, and $s' = s$, see Appendix 1\footnote{这里的Appendix 1是标准的Appendix，不是本讲义的。}.\par

If v does not equal $r'$, then the message may have been modified, the message may have been
incorrectly signed by the signatory, or the message may have been signed by an impostor. The
message should be considered invalid.


\subsubsection{RSA ds algorithm}
DSS中并没有规范RSA签名算法，而是引用了另外两个标准，这两个标准定义了RSA签名算法(见图\ref{ds-rsa-introduction})。
\begin{figure}[htbp]
	\centering
	\includegraphics[width=0.7\textwidth]{DSS-RSA-introduction.PNG}
	\caption{DSS中使用的RSA签名标准}
	\label{ds-rsa-introduction}
\end{figure}
\par
下面我们简单说一下RSA的签名原理。
\par
$pk_a,sk_a$分别表示a的公钥和私钥，H表示哈希函数，E表示加密函数，D表示解密函数，C表示一个数的比较函数，相当为真，不等为假，$a\rightarrow b:M$表示a把消息M发给b，$a\leftarrow b:M$表示b把消息M发到给a,$b:H(M)$表示在b端计算M的哈希值，那么RSA签名可以表示为：
\begin{enumerate}
	\item $a::ds=E_{sk_a}(H(M))$
	\item $a\rightarrow b::M || ds$
	\item $b::C(D_{pk_a}(ds),H(M))$为真则签名有效，否则签名无效。
\end{enumerate}
\par
\vspace{1cm}

在卿斯汉老师"密码学与计算机网络安全"\cite{qing-cry}一书中，讨论了A发送给B消息时，需要签名并加密：
\[ A::C=E_{pk_B} \left( D_{sk_A} \left( M\right) \right) \]
\[ A\rightarrow B:: C \]
B在收到C以后用私钥解密，用A的公钥解密，可以起到签名+加密，但是在这里其提到，当$n_A > n_B$时，$D_{sk_A} \left( M\right)$二进制块可能不在$[0,n_B -1 ]$的范围之内，将$D_{sk_A} \left( M\right)$对$n_B$取模也解决不了问题，因为取模后无法恢复M了。在卿老师的书中介绍了几种解决办法，比如重新分块、阈值(threshold value)方法和Konfelder方法。